1. The Field of the Invention
The present invention relates to electronic messaging and, more particularly, to failed message error recovery using application specific error queues.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, controlling home electronics, Web browsing, and printing documents) include the exchange of electronic messages between a number of computer systems and/or other electronic devices via wired and/or wireless computer networks.
Networks have in fact become so prolific that a simple network-enabled computing system may communicate with any one of millions of other computing systems spread throughout the globe over a conglomeration of networks often referred to as the “Internet”. Such computing systems may include desktop, laptop, or tablet personal computers; Personal Digital Assistants (PDAs); telephones; or any other computer or device capable of communicating over a digital network.
In order to communicate over a network, one computing system (referred to herein as a “sending computing system”) constructs or otherwise accesses an electronic message and transmits the electronic message over a network to another computing system (referred to herein as a “receiving computing system”). The electronic message may be read by a human user as when the electronic message is an e-mail or instant message, or may be read, instead, by an application running on the receiving computing system. The electronic message may be constructed by an application running on the sending computing system with the possible assistance of a human user.
In some environments, applications communicate with one another using queued message communication. Queued communication includes mechanisms for a sending application to write a message into a sending queue, the sending queue to transfer the message to a receiving queue, and for a receiving application to read the message from the receiving queue. The queues maintain communication state outside of the communicating parties, and provide a level of indirection between them. Accordingly, queued messaging provides reliable communication between loosely coupled applications. Senders and receivers of messages use intermediary queue managers to communicate, and may independently shut down and restart and may even have non-overlapping lifetimes. Queuing also allows clients and servers to send and receive messages “at their own pace” with the queue taking up the slack at either end
Similar to other types of messaging, queued messaging can fail for a variety of reasons. For example, an application may never run, and its messages will sit undelivered in a queue indefinitely. The sender's queue manager may be unable to connect to a receiver's queue manager. The receiver may reject the message for security or protocol-compliance reasons.
Reliability requires that errors be detected and handled. A message that cannot be successfully transferred or delivered should be reported. For example, if a message specifies the transfer of money from one account to another, the fact that the message could not be delivered needs to be reported to the client requesting the transfer. Because queued applications may shut down and restart before a message is delivered, reports of errors require persistent state. Typically, messages that fail are moved to so-called “dead queues”, which are queues similar to application queues, except that they hold messages that have failed. Each queue typically has a corresponding dead queue where it moves all messages that can not be delivered.
Thus, typically there is a single dead queue per queue manager. Thus, multiple applications at a computer system will often share the same dead queue. Sharing a queue manager among more than one application can be difficult if a particular application wishes to determine which of its messages could not be delivered. For example, referring back to the example of transferring money, an application may wish to find its undelivered message and report it to a user (e.g., through a user-interface) to provide the user the account, amount, and other information in the message along with any system diagnostic that indicated why the message went undelivered. Thus, if there is a single error queue per queue manager, then either the application must search the error queue for relevant errors, or the application must have the whole queue manager to itself. Unfortunately, searching a system-wide failed message queue for messages for a specific application requires cooperation between applications (which may not always be possible) and can be slow.
Each application that utilizes a shared message queue is typically given full access to the shared message queue. Full access allows each application to search for and retrieve its messages when a failure occurs. Unfortunately, when multiple applications share a failed message queue, data from one application can be exposed to other applications, which may be undesirable. For example, when a banking transaction fails, messages of the banking transaction can be transferred to the common failed message queue. These banking transaction messages are then visible to other applications that share the failed message queue. Thus, applications that would otherwise be prevented from accessing and/or manipulating the banking transaction messages on the wire may access and/or manipulate the banking transaction messages in the shared failed message queue
In some environments, it may be that each application has a corresponding queue manager and that each queue manager manages a corresponding failed message queue. Thus, these environments provide failed message queue isolation through the use of multiple queue managers and multiple corresponding failed message queues such that each failed message queue is utilized by a single corresponding application. However, operation and maintenance of multiple different queue managers and of message transfers over a corresponding number of transfer pipes to the different queue managers can significantly affect the performance of computer systems that implement such an arrangement.
Therefore systems, methods, and computer program products that facilitate failed message recovery using application specific error queues would be advantageous.